スクラムでプロジェクトを始める前にお客様に説明しておきたいスクラムのエッセンス

#アジャイル

#スクラム

かみと

2022.08.19

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

みなさんこんにちは、CX事業本部Delivery部のかみとです。

受託開発のプロジェクトをスクラムで始める際、アジャイル開発やスクラムのフレームワークに対する認識がお客様とベンダー間で一致していることが望ましいのですが、アジャイルやスクラムの経験有無、理解度の違いなどによって異なった認識のままプロジェクトが開始してしまうことで、後々プロジェクトの進行に影響を及ぼしてしまうことがあると思います。

これがただの小さな認識のズレで、プロジェクト進めていく中で調整可能なものであればいいのですが、そもそもの前提が違うくらいの大きな認識相違となってしまった場合、プロジェクトとしてはもちろんお客様との信頼関係にも悪影響を与えかねません。

そういった状況を避けるためにも、なるべくプロジェクト開始前にお客様との間でアジャイル開発にまつわる、よくある誤解を解消しておくのはとても大切なことだと思います。

このブログでは、スクラムでプロジェクトを始める際に、私が最初にお客様に伝えておきたいと思っているスクラムのエッセンスの部分を整理してみました。

スクラムガイドには載っていないけど、実際のプロジェクトでよくある誤解やアジャイルあるあるの内容が中心となっています。

別の言い方をすれば、どこかで誰かが言ったことの寄せ集めの情報とも言えます。すでにこの手の話は耳にタコだよという方はそっ閉じいただければと思います。

１．アジャイル≠コスト削減

最近こそあまり見かけることはなくなったと思いますが、「アジャイル導入によりコスト削減」や「納期の大幅な短縮に成功」といった記事のように、アジャイルをコスト対策の手段という見方で取り上げられることがあったように思います。

アジャイルは最小限で価値のある単位で開発し、短期間で動くものを早くリリースすることには違いありませんが、それは「早くリリースしてフィードバックをもらい、その結果を素早く適用する」ことが目的なので、その本質は「変化に適応する」という部分にあります。

プロダクトの初期リリースは実用最小限の製品（MVP）としてリリースするため、プロダクト初期リリースは比較的早い段階で行うことになりますが、この初期リリースはあくまでもMVPであり、当初の要件の全てを盛り込んだものではありません。

アジャイル開発においてはプロダクトは下図のように小さい単位で価値提供を行い、変化しながら進むこととなります。したがって、最終的にトータルコストで見るとウォーターフォール開発のような従来型の開発手法の予算より最終的にコストが上がっている可能性も否定できません。

逆に要件や機能詳細が最初から明確で、かつ要件変更が発生しないようなケースでは、ウォーターフォール開発のほうが効率的といえるでしょう。

しかし、ソフトウェア開発のあらゆる場面では、当初予定していた要件が不要になることは往々にしてあり得ます。

例えば以下のようなケースなどが考えられます。

必要と思われていた機能が実は使われていなかった
プロジェクトを進める中でより良い解決方法が見えてきた
時間の経過とともに技術そのものが陳腐化してしまった

そういった状況の変化に対応しながらプロジェクトの進行中であっても要件や優先順位を柔軟に変えられるというのがアジャイル開発の強みと言えます。また、そうして出来上がったものが当初予定していたものよりも無駄がなく、よりユーザー価値の高いものとなり、結果としてコスト対効果が高くなるというケースも十分にあり得ると思います。

２．タイムボックスの重要性

スクラムガイドでは、スプリントを「１ヶ月以内の決まった長さとする」と定義しています。前のスプリントが終わり次第、次のスプリントが始まります。

これは、そのスプリント内で行ったスプリントバックログのインクリメントが出荷可能な状態になっているかどうかに関わらず、「時間が来たら強制終了」を意味します。

「スプリント終了の時間だけど、まだインクリメント（作成物）ができてないので、１日延長お願いします！」はナシです。できなかったという事実を受け入れて、実際にリリース可能となった価値のみをチームの能力として計測します。

このリリース可能となった価値の大きさ（ストーリーポイント）の合計をベロシティとして表し、チームの生産能力として次のスプリント以降の予測に使用します。

この計測は、スプリントが固定されたタイムボックスにより区切られているからこそ可能となります。（ベロシティやストーリーポイントの詳細については、書籍『アジャイルな見積りと計画づくり～価値あるソフトウェアを育てる概念と技法～』がとても参考になります。）

ここがスクラムの経験主義を最も体現している部分と言えるかと思います。

このタイムボックスの重要性はお客様だけでなくスクラムチーム全員が認識しておく必要があります。

３．スクラムは鏡

スクラムチームは、スプリントの終わりにそのスプリントで作ったインクリメントをリリースします。スプリント開始時にプランニングで決めたゴールが達成できているかどうかを、スプリント毎にプロダクトオーナーとステークホルダーに説明するということで、これはつまりスプリントの度にチームが「うまく出来たのか、出来ていないのか」という事実を突きつけられることになります。

私が受講した認定スクラムマスター研修のスクラムトレーナーは、「スクラムをやればうまくいくのではなく、スクラムはいかにチームが『出来ていないか』を見せつけられる鏡だ」と表現されていて、これはとてもわかりやすいメタファーだと思いました。

また私の友人が言っていた「毎日体重計に乗るような感覚」という喩えも言い得て妙だと思っています。

フィードバックサイクルが長ければ長いほど様々な問題は蓄積しやすくなり、いざ対処が必要とわかった時にその切り戻しコストが増大することになります。

今の状態を包み隠さず評価して、その結果をもとに目標を再設定する、このフィードバックループを素早く回すことで、より良いゴールに向けた軌道修正をすることが可能になります。

４．プロジェクト開始当初など、ベロシティが上がらない時期もある

プロジェクト開始時期にはなかなか足並みが揃わなかったり、外堀りを埋めながら進める必要があったりで思うように開発スピードが上がらないことがよくあります。最初の生みの苦しみの時期ですね。

スクラムでは前述の通りスプリントとして期間を区切るため、こういう初期のスプリントでも無慈悲にスプリントレビューはやってきます。そういう時期はなかなか進捗が出ずお客様もチームも不安になるものです。

ただ、この時期に自分たちにはスクラムが合っていなかったのと判断を下すのはまだ時期尚早と言えます。スプリントが進むにつれて徐々に歯車が噛み合ってくれば開発のリズムが掴めてくるはずです。

この最初の時期に不安に陥らないためにも、この傾向についてはプロジェクト開始時に予めお客様に認識しておいてもらうのが得策かと思います。

５．スプリントゴール達成率は50%が健全

これは『組織パターン』の著者であるジェームス・コプリエン氏が2020年のRegional Scrum Gathering Tokyoのイベント内で仰っていて、とても印象深く心に残っており、今でも時折、反芻する言葉です。

正しく表現できるかわかりませんが、私なりの解釈で言語化してみたいと思います。

この言葉の前提として「スクラムチームは作業見積もりにバッファを持たない」ということがあると思っています。

スクラムチームはスプリントプランニングで実行する作業を計画します。そして開発チームはこのスプリントのゴールを達成するために全力を尽くします。前述の通り、スクラムの見積もりの指標としてよく使われるのがストーリーポイントです。そしてスプリントでどれだけストーリーポイントが完成できたかをベロシティとして表現します。そしてスプリントプランニングでは、このベロシティを元に次のスプリントで実行可能な作業量を計画します。

また、スクラムのフレームワークには「検査」と「適応」があるように、常に改善のサイクルが組み込まれています。

スクラムチームはこの「ベロシティによる作業予測」と「検査による改善サイクル」そして「適応によるチャレンジ」を繰り返しながら、素早くより高い品質で価値を届けるにはどうするべきかを自身に問い続けます。

スプリントゴールの達成率が50%ということは、より高いゴールのために実験とチャレンジを継続しているということの現れであり、これはスクラムが健全に機能していることを表していると解釈できます。

もしこの達成率が80%や90%となった場合、何かしらのバッファを含めたゴール設定となっている可能性があり、ジェームス・コプリエン氏は『これはチートだ！』と仰っていました。

またパーキンソンの法則にあるように、バッファは常に使い切ってしまうというフォースが働きます。

作業量に余裕を持つこと自体が悪だとは個人的には思いませんが、チーム文化としてチャレンジと失敗を許容する寛容さ、またお客様との間に信頼と透明性があるからこそ可能になる考え方の一つだと思いました。